home *** CD-ROM | disk | FTP | other *** search
/ Info-Mac 1993 May / Info-Mac_II_May_1993.to_.sit / Info-Mac II (May 1993).toast / Technical / mac-binary-ii-plus-prelim.txt < prev    next >
Internet Message Format  |  1993-03-27  |  5KB
  1. Date: Tue, 9 Feb 1993 15:37:11 +0800 
  2. From: Peter N Lewis <peter@cujo.curtin.edu.au>
  3. Subject: tech/macbinary2+specs.txt 
  4.  
  5. This is a priliminary specification of an extension to the MacBinary II 
  6. Standard to allow MacBinary to incorporate a directory tree in a similar 
  7. way to a unix tar file.  This is done by a fairly simple extension to 
  8. the standard (which is documented seperately, and which you should be 
  9. familiar with before reading this document).  This extension is implemented
  10. by MacBinary II+ posted at the same time.
  11.  
  12. **** Cut here ****
  13. MacBinary II+ Preliminary Specification
  14.  
  15. This is a priliminary specification of an extension to the MacBinary II 
  16. Standard to allow MacBinary to incorporate a directory tree in a similar 
  17. way to a unix tar file.  This is done by a fairly simple extension to 
  18. the standard (which is documented seperately, and which you should be 
  19. familiar with before reading this), basically, I defined a 128 byte 
  20. block that marks the start of a folder, and another one that marks the 
  21. end of the folder, and then set it up like this:
  22.  
  23. start block for folder "Folder1"
  24.   file1 - standard macbinary format
  25.   file2
  26.   start block for "Folder2"
  27.     file3
  28.   end block
  29. end block
  30.  
  31. While the end block doesn't actually need to contain any information, its 
  32. format is similar to the header block for consistency.
  33.  
  34. Start Block:
  35.   Offset 000-version 1 - this is incomptible with previous decoders.
  36.   Offset 001-Byte, Length of foldername (must be in the range 1-63)
  37.   Offset 002-1 to 63 chars, foldername (only "length" bytes are significant, 
  38.              the rest should be zero).
  39.   Offset 065-Long Word, file type - 'fold'
  40.   Offset 069-Long Word, file creator - $FFFFFFFF
  41.   Offset 073-Byte, original Finder flags of folder (high byte)
  42.   Offset 074-Byte, zero fill, must be zero for compatibility
  43.   Offset 075-Word, folder's vertical position within its window.
  44.   Offset 077-Word, folder's horizontal position within its window.
  45.   Offset 079-Word, folder's window or folder ID.
  46.   Offset 081-Byte, "Protected" flag (in low order bit).
  47.   Offset 082-Byte, zero fill, must be zero for compatibility
  48.   Offset 083-Long Word, Data Fork length 0
  49.   Offset 087-Long Word, Resource Fork length 0
  50.   Offset 091-Long Word, Folder's creation date
  51.   Offset 095-Long Word, Folder's "last modified" date.
  52.   Offset 099-Word, length of Get Info comment to be sent after the resource
  53.              fork (if implemented, see below).
  54.  *Offset 101-Byte, Finder Flags, bits 0-7. (Bits 8-15 are already in byte 73)
  55.  *Offset 116-Long Word, Length of total files when packed files are unpacked.
  56.              This may be zero to avoid having to preparse the folder when
  57.              creating the MacBinary file.
  58.  *Offset 120-Word, Length of a secondary header.  If this is non-zero,
  59.              Skip this many bytes (rounded up to the next multiple of 128)
  60.              This is for future expansion only, when sending files with
  61.              MacBinary, this word should be zero.
  62.  *Offset 122-Byte, Version number of Macbinary II - 130
  63.  *Offset 123-Byte, Minimum MacBinary II version needed to read this file - 130
  64.  *Offset 124-Word, CRC of previous 124 bytes
  65.  
  66. NOTE: The secondary header length MAY be non-zero, and if so, the secondary 
  67. header immediately follows the Start Block, padded to a multiple of 128 bytes 
  68. as usual.
  69.  
  70. NOTE: The comment length MAY be non-zero, and if so, the comment immediately 
  71. follows the Start Block or secondary header, padded to a multiple of 128 
  72. bytes as usual.
  73.  
  74. End Block:
  75.   Offset 000-version 1 - this is incomptible with previous decoders.
  76.   Offset 065-Long Word, file type - 'fold'
  77.   Offset 069-Long Word, file creator - $FFFFFFFE
  78.  *Offset 116-Long Word, Length of total files when packed files are unpacked.
  79.              This may be zero.
  80.  *Offset 120-Word, Length of a secondary header.  If this is non-zero,
  81.              Skip this many bytes (rounded up to the next multiple of 128)
  82.              This is for future expansion only, when sending files with
  83.              MacBinary, this word should be zero.
  84.  *Offset 122-Byte, Version number of Macbinary II - 130
  85.  *Offset 123-Byte, Minimum MacBinary II version needed to read this file - 130
  86.  *Offset 124-Word, CRC of previous 124 bytes
  87.  
  88. NOTE: This block is static except for the total length field, which may be 
  89. zero as well, in which case its totally static.
  90.  
  91. You should recognize the Start and End blocks by the version, file type and 
  92. creator fields.  Decoders MUST NOT rely on ANY other fields in the End Block 
  93. being valid.  Encoders MAY fill them out to look like a start block, or may 
  94. zero-fill them.  Encoders SHOULD zero-fill any bytes not explicitly set - 
  95. this applies to all header blocks and all padding.
  96.  
  97. All internal files should have version 0, MacBinary II version 129,129.
  98.  
  99. An extended MacBinary file MUST start with a Start Block.  Thus a 
  100. MacBinary II+ file is either:
  101. 1) A MacBinary II file encoding a single file, OR
  102. 2) A MacBinary II+ file encoding a single folder.
  103. **** Cut here ****
  104.  
  105.  
  106.  
  107.